Nomadic Honeypots: A Novel Concept for Smartphone Honeypots

Intelligence on mobile threats is a valuable asset. Honeypots showed to provide a good resource to gain threat intelligence in other areas. Unfortunately, current malware largely relies on social engineering to infect smartphones. Recently, attacks against smartphones have shifted towards local communication interfaces. These trends make traditional honeypot concepts unsuitable. We propose a novel concept called nomadic honeypot that provides an infrastructure to enable mobile network operators to collect threat intelligence directly on smartphones. We present a practical design that confines the mobile operating system in a virtual machine. Through virtualization all communication interfaces can be monitored. The actual monitoring is carried out by a second virtual machine running on the same device. This machine hosts sensors and provides a secure backchannel for the operator. Our nomadic honeypot is meant to be used by people. Thus it has the capability to catch malware that is distributed through app stores as well as future threats that attack the smartphone using local communication such as NFC, Bluetooth, and QR codes. We implemented a prototype that runs on an off the shelf smartphone. Keywords-smartphone, honeypot, malware, worms, threat intelligence, system virtualization With rising popularity, smartphones become increasingly attractive for malware. In fact, smartphone security–or the lack thereof–has reached a level of publicity, where customers are very conscious about it. With security becoming a selling argument, being able to warn and protect customers becomes a valuable asset for cellular operators. Zhou et al. [12] found 93% of malware samples to employ C&C channels, which makes them bots. Such botnets can be very harmful to the core cellular network [11]. Therefore it is in the interest of the operators to know about such threats in order to be able to enact countermeasures. In IP networks Honeypots have been successfully used to collect threat information. However, the classical passive IPbased Honeypot does not fit the infection vectors on smartphones. Most malware today is being installed by the user himself, for example when he installs an infected App from a black market. We also observed the first infections through malicious Quick Response (QR) codes [1]. We observe that the smartphone and its user form a ”very high interaction” honeypot. The key insight is that the user is a part of the honeypot. The user involuntarily increases the honeypot’s visibility, when he installs malware, scans malicious QR codes, and interacts with malicious NFC devices and RFID tags. With this insight, we determined that the best place to collect intelligence on current mobile threats is the device itself. To this end, we introduce the concept of nomadic honeypots. Today about 37% [12] of Android malware contains root exploits to elevate its privileges. If it succeeds all security measures of the operating system (OS) become useless. Thus we cannot host our solution in the mobile OS itself. Instead we divide the device into two logical partitions. We move the entire mobile OS into its own partition and remove its direct access to the device’s communication hardware. In a second partition we host the nomadic honeypot infrastructure. It has four obligations: First it controls the communication interfaces and mediates all communication of the mobile OS. Second it hosts a wide range of sensors to collect and filter events on the communication interfaces. Third it implements facilities for snapshots and logging of the mobile OS. Fourth it establishes a secure backchannel to communicate with the operator. To show how nomadic honeypots can be constructed in practice, we present a design that is based on a modern microkernel. We implement the partitions with virtual machines (VMs). We implemented a prototype that runs on an off the shelf Samsung Galaxy S2 smartphone. Our contributions are: • Concept of nomadic honeypots We introduce nomadic honeypots as an infrastructure to collect information on threats directly on mobile devices. • Practical design We present a practical design of our nomadic honeypot. We employ virtualization to confine the mobile OS and remove its direct access to communication hardware. We mediate all communication in a separate VM, where we deploy sensors which collect information, and a secure backchannel. This paper is structured as follows. We introduce the concept of nomadic honeypots in Section I. Then we show how a nomadic honeypot can be constructed in practice in Section II. We show our prototype in Section III, and present ideas for sensors in Section IV. Sections V and VI discuss the ethical implications of nomadic honeypots and how operators can deploy them. We conclude in Section VII. I. CONCEPT OF A NOMADIC HONEYPOT The nomadic honeypot is deployed directly on a smartphone. In our concept the user plays a key role, as he is responsible for the visibility of our honeypot: He moves the honeypot into interesting areas, scans malicious QR codes and installs malicious applications. Ideally the nomadic honeypot is the primary smartphone of the user that he uses on a daily basis. We discuss an idea on how operators can make people use nomadic honeypots in Section VI. Conceptually the nomadic honeypot requires that the smartphone is logically divided into two isolated partitions. The main partition hosts the mobile OS, but has no direct access to the device’s communication hardware. Malware often includes checks if it is being run in an unusual environment such as an emulator, and turns off its malicious payload to escape detection. Therefore it is vital that the mobile OS is modified as little as possible. The second partition hosts the infrastructure for our nomadic honeypot. It has four obligations: First, it mediates all communication of the mobile OS. Second, it hosts infrastructure for data collection (sensors). Third, it implements facilities for snapshots and logging. And fourth, it provides a secure backchannel for the operator. Mediating all communication serves two purposes. First, it allows for powerful sensors that can monitor the data stream directly and no communication goes unnoticed. Second, it allows us to confine malware and stop it from spreading. Strict isolation between the partitions ensures that even a subverted mobile OS cannot tamper with the nomadic honeypot’s infrastructure. Therefore the operator can trust in the information that is being collected by the nomadic honeypot. Cryptographic keys that are needed to establish the backchannel remain confidential, and an attacker cannot use them to connect to the operator. The operator can use the collected data to gain intelligence on mobile threats. He can request snapshots of the mobile OS’s file system to do an offline forensic analysis of attacks. Thereby he can gain thorough insight on the nature of the threats and use his findings to protect his customers. An illustration of nomadic honeypots in action is given in Figure 1. II. DESIGN OF A PRACTICAL NOMADIC HONEYPOT In this section we show how a nomadic honeypot can be constructed for today’s smartphone hardware. The most prominent question is how to partition the device. ARM TrustZone [10] implements partitioning in hardware. We want to be able to deploy our nomadic honeypot to all smartphones. Therefore TrustZone is not an option because it is not implemented in all smartphones. Even if it is implemented, it is usually not available because the OEM already deployed a secure monitor that cannot be replaced. Instead we opt to do virtualization on a microkernel. As shown by Lange et al. [7] virtualization of mobile OSes like Android is possible even on Operator Malicious WiFI Inform In fo rm